A Brief Guide to GitLab CI Runners and Executors

A Brief Guide to GitLab CI Runners and ExecutorsIf you wish to create your own infrastructure for running GitLab CI jobs, you need to host your own GitLab Runners. But which executor to select? Shell, SSH, or Docker? Or something else?

Valentin Despa

Published in

DevOps with Valentine

·7 min read·Nov 10, 2021

GitLab CI employs a different architecture, compared to the default installation of more traditional CI servers, like Jenkins. In a nutshell, the GitLab server will always delegate the work of actually running a job to a GitLab Runner, which will sit somewhere on a different server.

Here are the most important concepts you need to understand:

GitLab Job: the smallest component of a pipeline, which contains one or more commands that need to be executed.GitLab Runner: this is an agent installed on a different server from the GitLab server. The GitLab Runner receives instructions from the GitLab server in regards to which jobs to run. Each runner must be registered with the GitLab server.Runner Executor: each Runner will define at least one executor. An executor is essentially the environment where the job will be executed.

With GitLab, you can use different executors, depending on your needs:

ShellSSHVirtualBoxParallelsDocker

云奕文章网

A Brief Guide to GitLab CI Runners and Executors

相关推荐：